What the bug is

After the polling loop at line 325, handleAutomaticTaskPolling unconditionally calls getTaskResult and validateToolOutput at lines 335-336. However, the while loop exits when task.status is any of completed, failed, or cancelled. For failed or cancelled tasks, calling validateToolOutput is semantically wrong — a failed task should surface its failure reason, not have its output validated against a schema.

The triggering code path

1. A tool is registered with taskSupport: "optional", an outputSchema, and a task handler.
2. A client calls this tool WITHOUT task augmentation (request.params.task is falsy).
3. Execution enters handleAutomaticTaskPolling at line 193.
4. The task handler runs, but the task eventually fails. The handler calls storeTaskResult with a result that has content but does NOT set isError: true and does NOT include structuredContent. This is valid — the task status field (failed) indicates failure, not the isError flag.
5. The polling loop exits because task.status === "failed".
6. At line 335, getTaskResult retrieves the stored result successfully.
7. At line 336, validateToolOutput is called. It checks: outputSchema exists (yes), content in result (yes), result.isError (false — not set), result.structuredContent (undefined). It then throws ProtocolError(InternalError, "has an output schema but no structured content was provided").

Why existing guards do not prevent this

validateToolOutput has three early-return guards: (1) no outputSchema, (2) result is not a CallToolResult, (3) result.isError is true. For the described scenario, the tool has an outputSchema, the result is a CallToolResult with content, and isError is not set (since storeTaskResult does not enforce isError: true for failed tasks — confirmed by the test at inMemory.test.ts:535). None of the guards trigger.

Impact

The misleading ProtocolError about output schema masks the actual task failure. Instead of the client learning that the task failed (and why), it receives an opaque internal error about missing structured content. This is a narrow edge case requiring: taskSupport: "optional" + no task augmentation from client + task fails + result stored without isError: true + tool has outputSchema. But it was introduced by this PR (the validateToolOutput call at line 336 is new).

How to fix

Guard the getTaskResult/validateToolOutput calls with a status check:

if (task.status \!== "completed") {
    const result = await ctx.task.store.getTaskResult(taskId).catch(() => null);
    const message = result && "content" in result
        ? (result.content as Array<{text?: string}>)?.[0]?.text ?? `Task ${task.status}`
        : `Task ${task.status}`;
    throw new Error(message);
}

const result = (await ctx.task.store.getTaskResult(taskId)) as CallToolResult;
await this.validateToolOutput(tool, result, request.params.name);
return result;

Or more minimally, just guard validateToolOutput:

const result = (await ctx.task.store.getTaskResult(taskId)) as CallToolResult;
if (task.status === "completed") {
    await this.validateToolOutput(tool, result, request.params.name);
}
return result;